Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-149.txt

Text File | 1994-12-08 | 49.8 KB | 1,240 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 02 Aug 92       Volume 1 : Issue 149

Today's Topics:

    MPW:  Tool to "execute" Finder Aliases
    32-bit compatibility
    The "New" Sound Manager (Was: Audio CD File Format)
    Why can't my unix box compile my Mac source?
    OCE Finder and Macintosh PC Exchange
    Drawing a "graph" of a sound



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Clay Luther)
Subject: MPW:  Tool to "execute" Finder Aliases
Date: 18 Jun 92 23:04:24 GMT
Organization: University of North Texas

I currently have a problem (caused by TOPS) that I need to work around.

We use TOPS to connect to our Unix boxes where we store common code between
our Mac and Unix programs.  Our MPW environment is setup to expect certain
Unix volumes to be mounted when MPW kicks off (these are normally mounted
at start-up).

However, the natures of my job require me to have FileSharing running on my
machine as well.  If I automatically mount TOPS volumes at start-up, File
Sharing will not come up.

I was trying to figure some way for MPW to automatically mount the TOPS
volumes through a Finder alias file (I have the aliases to the servers in my
Apple Menu) - that is, I'd like to coax MPW to "execute" the Finder aliases
for these servers.

I expect a tool that issues an ODOC event to the Finder might just do the trick.

Has anyone written something that could help me?

Thanks.

- --
Clay W. Luther                  [e-mail]
Macintosh/Unix Programmer for Vortech Data, Inc.
Virtual System Consultant for the UNT Center for Network Neuroscience
[phone]

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 19 Jun 92 20:19:59 GMT
Organization: Taligent, Inc.

In article <cluther.708908664@morticia>, [e-mail]
(Clay Luther) wrote:
>
> I was trying to figure some way for MPW to automatically mount the TOPS
> volumes through a Finder alias file (I have the aliases to the servers in my
> Apple Menu) - that is, I'd like to coax MPW to "execute" the Finder aliases

I wrote an MPW tool that resolves an alias file and outputs the resulting
pathname.  I find it very useful for writing scripts that need to access
remote servers, etc.

You can find it along with a couple of other System 7-related MPW tools and
the Pascal sources on ftp.apple.com in /pub/lsr.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Date: 22 Jun 92 15:56:05 GMT
Organization: Digital Technology, International

In article <cluther.708908664@morticia> [e-mail] (Clay Luther) writes:
>I currently have a problem (caused by TOPS) that I need to work around.
>
>We use TOPS to connect to our Unix boxes where we store common code between
>our Mac and Unix programs.  Our MPW environment is setup to expect certain
>Unix volumes to be mounted when MPW kicks off (these are normally mounted
>at start-up).
>
>However, the natures of my job require me to have FileSharing running on my
>machine as well.  If I automatically mount TOPS volumes at start-up, File
>Sharing will not come up.
>
>I was trying to figure some way for MPW to automatically mount the TOPS
>volumes through a Finder alias file (I have the aliases to the servers in my
>Apple Menu) - that is, I'd like to coax MPW to "execute" the Finder aliases
>for these servers.
>
>I expect a tool that issues an ODOC event to the Finder might just do the trick.
>
>Has anyone written something that could help me?
>
>Thanks.
>
>--
>Clay W. Luther                  [e-mail]
>Macintosh/Unix Programmer for Vortech Data, Inc.
>Virtual System Consultant for the UNT Center for Network Neuroscience
>[phone]

You don't really need anything new, MPW has a 'choose' tool that
will allow you to mount volumes.  Here are some key bindings I use
to mount files, you could just put the 'choose' code in your startup
and it will automatically mount the partition/disk:

    setkey    command-shift-option-control-F1
        '"{sysfolder}Apple Menu Items:chooser"'
    setkey    command-shift-option-control-F2
        'choose -u Dev "R&D Ethertalk":SunServer:DD45'
    setkey    command-shift-option-control-F3
        'choose -u Dev "R&D Ethertalk":SunServer:RandD'

(NOTE: there are only three lines above, they've been broken in two
so they don't wrap uglily :-).  Do a help on 'setkey' and 'choose'
to find out the correct syntax, you can specify passwords with
choose.

- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

---------------------------

From: [e-mail] (Bill Cramer)
Subject: 32-bit compatibility
Organization: Unixland Public Access Unix  [phone]
Date: Sun, 21 Jun 1992 02:31:48 GMT

(woops, this ended up in the wrong group last time...)

A simple question -- how do I establish whether or not a program
is 32-bit compatible?  I have a written a program with Think C,
and it runs without any (apparent) problems on a Mac II (Sys 7, 8Mb
memory, with MODE32 installed).  Does this mean that the program is
32-bit compatible?

Bill Cramer

251 West Central Street, Suite 142    | "You can buy better,
Natick, MA 01760 USA            |    but you just can't pay more."
Internet: [e-mail]    |
CIS: 70322,3412                |



+++++++++++++++++++++++++++

From: John Lacey <[e-mail]>
Organization: Computer Science, Indiana University
Date: Sun, 21 Jun 1992 00:30:24 -0500

[e-mail] (Bill Cramer) writes:

>[The program] runs without any (apparent) problems on a Mac II (Sys 7,
>8Mb memory, with MODE32 installed).  Does this mean that the program is
>32-bit compatible?

Yes, and it's also completely free of bugs and has a well-designed
human interface.  (Sorry, but I couldn't resist.)  :-}

>How do I establish whether or not a program is 32-bit compatible?

The main features of 32-bit clean are:
1) Never set the bits in a pointer or handle explicitly.
2) Never compare more bits than contain a valid address.

These are spelled out in more detail in Inside Mac VI, a Tech Note on
StripBits, and at least one more tech note whose topic and title
escape me at the moment.

This covers everything from always using system calls to create and
modify pointers and handles (NewHandle, HLock, HGetState, &c) to
calling StripBits before comparing two addresses in 24-bit mode.
- --
John Lacey        Whatever you can do, or dream you can, begin it;
                  Boldness has genius, power, and magic in it.      --- G"othe

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Actrix Information Exchange
Date: Sun, 21 Jun 1992 04:48:46 GMT

In article <[e-mail]> [e-mail] (Bill Cramer) writes:
>
> A simple question -- how do I establish whether or not a program
> is 32-bit compatible?  I have a written a program with Think C,
> and it runs without any (apparent) problems on a Mac II (Sys 7, 8Mb
> memory, with MODE32 installed).  Does this mean that the program is
> 32-bit compatible?

All normal  programs are automatically 32-bit compatible unless you actively
do something to stop them being so, such as attempting to lock a
handle yourself instead of using the ROM routines.

The empirical method of "try it and see" should work reasonably
reliably, but not on a machine with only 8 MB of RAM.  Try it on a
machine with more than 8 MB RAM (and preferebly more than 16 MB) and
drop into Macsbug and check that the program actually got loading into
high memory.

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (Bathsheba Grossman)
Organization: Extended Bulletin Board Service
Date: Mon, 22 Jun 1992 04:02:06 GMT

In article <[e-mail]> John Lacey <[e-mail]> writes:
>[e-mail] (Bill Cramer) writes:
>>How do I establish whether or not a program is 32-bit compatible?
>
>The main features of 32-bit clean are:
>1) Never set the bits in a pointer or handle explicitly.
>2) Never compare more bits than contain a valid address.
>
>These are spelled out in more detail in Inside Mac VI, a Tech Note on
>StripBits, and at least one more tech note whose topic and title
>escape me at the moment.

(Actually I think this trap is called StripAddress.)  Also, if you
have any CDEF's you have to adjust them as per IM VI 28-12, because of
the calcCRgns message, which uses the top byte of a handle in a most evil
fashion.  This is also documented in TN#196, CDEF Parameters.

- -Sheba
[e-mail]
- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 22 Jun 1992 12:51:39 GMT

To make sure your app i 32-bit clean, read the Compatibility Chapter in
IM-VI about it and make sure you are followingthe rules listed there:

ie: Call HLock and HUnlock as opposed to manipulating bits directly. etc.


- --
- -- joe zobkiw                      Internet: [e-mail]
- --                                      AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP
- -- asm.comm.networks.cool tunes...

---------------------------

From: [e-mail] (Herb Poppe)
Subject: The "New" Sound Manager (Was: Audio CD File Format)
Organization: Scientific Computing Division/NCAR Boulder, CO
Date: Thu, 28 May 1992 17:10:24 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:

> Whenever the new sound manager is finished, ...

Matt's statement inspires the following comment:

The Sound Manager (SM) has always been "The New Sound Manager". The very
first SM was "new" because it replaced (NOT) the Sound Driver. The next SM
was "new" because it replaced the first SM. There have been several "new"
SMs since then. With all these "new" SMs, the adjective "new" has lost all
meaning. Do these SMs have version numbers that we can talk about? What is
the version number of the new SM? Is that something I can find out from
Gestalt?

Have I missed the point? Or is it really a Manager for New Sounds?   :-)

Herb Poppe                 National Center for Atmospheric Research (NCAR)
[e-mail]       1850 Table Mesa Dr.
[phone]             Boulder, CO  80303

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 29 May 92 00:08:07 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Herb Poppe) writes:
>
> In article <[e-mail]> [e-mail] (Matt Mora) writes:
>
> > Whenever the new sound manager is finished, ...
>
> Matt's statement inspires the following comment:
>
> The Sound Manager (SM) has always been "The New Sound Manager". The very
> first SM was "new" because it replaced (NOT) the Sound Driver. The next SM
> was "new" because it replaced the first SM. There have been several "new"
> SMs since then. With all these "new" SMs, the adjective "new" has lost all
> meaning. Do these SMs have version numbers that we can talk about? What is
> the version number of the new SM? Is that something I can find out from
> Gestalt?

We called the Sound Manager that shipped in 6.0.7 and finally with System
7.0 the "New Sound Manager."  All previous versions were called simply
the "Sound Manager."

The trap SndSoundManagerVersion first appeared in the "new" version,
originally shipping with System 6.0.7.  This trap is not present on any
previous version of the System.

The "new" version (which impliments the SndSoundManagerVersion trap) retuns
a version of 0x02008000.  (Hmm, I think there was a mistake in the build
process and it returned a non-final version number for System 6.0.7)
This is the standard NumVersion structure from the 'vers' resource
defined in the File System interfaces.  Good place for it, huh?

So the "new" version of the Sound Manager, which is the first version
that ever had a "version", that shipped in System 6.0.7 is version 2.0.
The version in System 7.0 was 2.0.1.

There's another thing called the versionCmd, which can be sent to any
snth with the SndControl trap.  This returns the version of the 'snth'
your using in that channel.

OK?



- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Herb Poppe)
Organization: Scientific Computing Division/NCAR Boulder, CO
Date: Fri, 29 May 1992 15:26:56 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:

> Whenever the new sound manager is finished, ...

In article <[e-mail]>, [e-mail]
(Herb Poppe) writes:

> Matt's statement inspires the following comment:
>
> The Sound Manager (SM) has always been "The New Sound Manager".
> ...
> What is the version number of the new SM?

In article <[e-mail]> [e-mail] (Jim Reekes)
writes:

> We called the Sound Manager that shipped in 6.0.7 and finally with System
> 7.0 the "New Sound Manager."  All previous versions were called simply
> the "Sound Manager."
> ...
> So the "new" version of the Sound Manager, which is the first version
> that ever had a "version", that shipped in System 6.0.7 is version 2.0.
> The version in System 7.0 was 2.0.1.

Ah, but the "new" Sound Manager that Matt and I are speaking of is the New
Sound Manager that was discussed at the WWDC!   :-)

Herb Poppe                 National Center for Atmospheric Research (NCAR)
[e-mail]       1850 Table Mesa Dr.
[phone]             Boulder, CO  80303

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Bader)
Organization: Xerox Imaging Systems, Inc.
Date: Wed, 10 Jun 1992 21:27:12 GMT

>We called the Sound Manager that shipped in 6.0.7 and finally with System
>7.0 the "New Sound Manager."  All previous versions were called simply
>the "Sound Manager."
>
>The trap SndSoundManagerVersion first appeared in the "new" version,
>originally shipping with System 6.0.7.  This trap is not present on any
>previous version of the System.
>
>The "new" version (which impliments the SndSoundManagerVersion trap) retuns
>a version of 0x02008000.  (Hmm, I think there was a mistake in the build
>process and it returned a non-final version number for System 6.0.7)
>This is the standard NumVersion structure from the 'vers' resource
>defined in the File System interfaces.  Good place for it, huh?
>
>So the "new" version of the Sound Manager, which is the first version
>that ever had a "version", that shipped in System 6.0.7 is version 2.0.
>The version in System 7.0 was 2.0.1.
>

Does this mean that the Sound Manager described in IM VI is present in full in 6.0.7?



+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 Jun 92 00:18:22 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Christopher Bader) writes:
>
> >We called the Sound Manager that shipped in 6.0.7 and finally with System
> >7.0 the "New Sound Manager."  All previous versions were called simply
> >the "Sound Manager."
> >
> >The trap SndSoundManagerVersion first appeared in the "new" version,
> >originally shipping with System 6.0.7.  This trap is not present on any
> >previous version of the System.
> >
> >The "new" version (which impliments the SndSoundManagerVersion trap) retuns
> >a version of 0x02008000.  (Hmm, I think there was a mistake in the build
> >process and it returned a non-final version number for System 6.0.7)
> >This is the standard NumVersion structure from the 'vers' resource
> >defined in the File System interfaces.  Good place for it, huh?
> >
> >So the "new" version of the Sound Manager, which is the first version
> >that ever had a "version", that shipped in System 6.0.7 is version 2.0.
> >The version in System 7.0 was 2.0.1.
> >
>
> Does this mean that the Sound Manager described in IM VI is present in
> full in 6.0.7?



Yes, but it's basically a "beta" version of the 7.0 Sound Manager.

- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."


---------------------------

From: [e-mail] (Matt Mora)
Subject: Why can't my unix box compile my Mac source?
Date: 2 Jun 92 21:12:16 GMT
Organization: SRI International, Menlo Park, California

With all this talk about toolserver and the like, how
come no one has come up with a way for me to tell the unix
box to compile some source and let the mac link its output?

You you figure that with all these net.guru's bragging about
how much better the compilers are for their unix machines
that they would figure out a way to use tool server or an MPW
tool let the unix box compile their source while they do something
on their mac. Wouldn't this be a great idea? I think Steve Dorner
does something like this but he might compile on his mac. But
he uses emacs and the source code system on his unix box.

Is something like this possible?

Just curious. If it was, I sure would run out and get me an eithernet
card and seriously consider using MPW. :-)

Matt


- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Wed, 3 Jun 1992 15:09:42 GMT

[e-mail] (Matt Mora) writes:
>With all this talk about toolserver and the like, how
>come no one has come up with a way for me to tell the unix
>box to compile some source and let the mac link its output?

Because it's a lot of work, requiring detailed knowledge of things
most of us really would rather not think about.

>that they would figure out a way to use tool server or an MPW
>tool let the unix box compile their source while they do something
>on their mac. Wouldn't this be a great idea?

Yes.

>I think Steve Dorner
>does something like this but he might compile on his mac.

Right.

>he uses emacs and the source code system on his unix box.

Not emacs.  Otherwise, yes.

>Is something like this possible?

Of course.  Sumacc worked this way, ages ago.  It probably isn't even too
hard, given gcc.  However, there are a lot of really arcane things to worry
about, like pascal calling conventions.  I suspect that most of this work
is already done, in the Apple port of gcc for MPW 2.  However, there are still
drawbacks; Apple's gcc port, for example, didn't emit SADE symbols.

To make a long story short, it's a great idea, but not trivial.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Wed, 3 Jun 1992 17:27:55 GMT

In article <[e-mail]> [e-mail] (Matt Mora) writes:
>With all this talk about toolserver and the like, how
>come no one has come up with a way for me to tell the unix
>box to compile some source and let the mac link its output?
>[...]
>Is something like this possible?

Possible, yes :-) But I don't think many people do it. Isn't Microsoft supposed
to do all their development on Unix boxes ?

It should be possible to retrofit the mac version of gcc to run on unix again,
but someone would have to write an assembler for it that generates the correct
.o files (COFF2MPW, anyone ?).

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

+++++++++++++++++++++++++++

From: [e-mail] (Eric Schlegel)
Date: 5 Jun 92 15:29:38 GMT
Organization: Microsoft Corporation

In article <[e-mail]> [e-mail] (Matthias Neeracher) writes:
>In article <[e-mail]> [e-mail] (Matt Mora) writes:
>>With all this talk about toolserver and the like, how
>>come no one has come up with a way for me to tell the unix
>>box to compile some source and let the mac link its output?
>>[...]
>>Is something like this possible?
>
>Possible, yes :-) But I don't think many people do it. Isn't Microsoft supposed
>to do all their development on Unix boxes ?

We did at one point, but that was years and years ago (early 80's). Nowadays
I think about 10 people in the entire company still do development on Xenix;
most development is on PCs or Macs.

- -eric
- -------
My opinion, not Microsoft's.

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 23 Jun 1992 17:44:05 +0200
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Matthias Neeracher) writes:
<
< It should be possible to retrofit the mac version of gcc to run on unix again,
< but someone would have to write an assembler for it that generates the correct
< .o files (COFF2MPW, anyone ?).
<
coff2mpw does exist. I wrote it a few months ago as a Perl script.  ;-)

HOWEVER, the Unix C compilers generate absolute references. MPW object files
can't have absolute references for anything except data->data because (a)
code->data references can't be patched (code resources are supposed tro be
write-only) and (b) anything->code references can't be absolute because the
code resource in question may move. Because there's no indication as to where
the absolute-referencing instruction is, if any, the Linker can't do anything
about this problem either.
As a result, if you want to use the resulting code, you'll have to load it
into global data space (which isn't relocatible), let the _DataInit() patch
up the absolute references for you, and essentially jump into your data space.

It works. But it's ugly. And we haven't even talked about the fact that
there's no such thing as an A5 world under Unix. This means that a Unix
compiler is free to clobber the A5 register as long as it restores it on
procedure exit. This means that if your Unix code calls your Mac code in
any way at all, you'll have no A5 register and will sooner or later crash
your system unless you're _very_ careful.

The resulting object files are very useful for being fed into DumpObj,
however. (I hate Unix assembler syntax.)
My code should be FTPable from iraun1.ira.uka.de, directory /pub/mac.

- --
"I can give you a sentence with the word punctilious.  There's
 a farmer with two daughters, Lizzie and Tillie.  Lizzie is
 all right, but you have no idea how punctilious."
- -- Another member of the Algonquin Round Table
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

---------------------------

From: ulbrich@second_next.informatik.uni-ulm.de (Jan Ulbrich)
Subject: OCE Finder and Macintosh PC Exchange
Organization: University of Ulm, Germany
Date: Thu, 4 Jun 92 09:26:14 GMT

Hi there,

I'm working on an extern filesystem for the Macintosh, but noone can
tell
me how to implement one. The developer-support can't help - though it
is
mentioned in Inside Macintosh IV to ask them for support. Any idea
where to
get information from? Please...

I read that the "Macintosh PC Exchange" can be extended by modules.
Would
this be a possibility to attach an extern filesystem? Where can I get
Information about this?

MacUP writes that the new O.C.E-Finder will be shiped this fall. Has
anyone
informations on how to extend the O.C.E.-mailing engine?

Thanks for reply and have a nice day, Jan

///  Jan Ulbrich -- flynn (remember tron?)
o-o  student at University of Ulm, Germany
 L
 _   address: [e-mail]


- -- NewsGrazer, a NeXTstep(tm) news reader, posting --
M>UQR=&8P7&%N<VE[7&9O;G1T8FQ<9C!<9FUO9&5R;B!#;W5R:65R.WT*7&UA
M<F=L,3(P"EQM87)G<C$R,`I<<&%R9%QT>#DV,%QT>#$Y,C!<='@R.#@P7'1X
M,S@T,%QT>#0X,#!<='@U-S8P7'1X-C<R,%QT>#<V.#!<='@X-C0P7'1X.38P
M,%QF,%QB,%QI,%QU;#!<9G,R-"!(:2!T:&5R92Q<"EP*22=M('=O<FMI;F<@
M;VX@86X@97AT97)N(&9I;&5S>7-T96T@9F]R('1H92!-86-I;G1O<V@L(&)U
M="!N;V]N92!C86X@=&5L;%P*;64@:&]W('1O(&EM<&QE;65N="!O;F4N(%1H
M92!D979E;&]P97(M<W5P<&]R="!C86XG="!H96QP("T@=&AO=6=H(&ET(&ES
M7`IM96YT:6]N960@:6X@26YS:61E($UA8VEN=&]S:"!)5B!T;R!A<VL@=&AE
M;2!F;W(@<W5P<&]R="X@06YY(&ED96$@=VAE<F4@=&]<"F=E="!I;F9O<FUA
M=&EO;B!F<F]M/R!0;&5A<V4N+BY<"EP*22!R96%D('1H870@=&AE(")-86-I
M;G1O<V@@4$,@17AC:&%N9V4B(&-A;B!B92!E>'1E;F1E9"!B>2!M;V1U;&5S
M+B!7;W5L9%P*=&AI<R!B92!A('!O<W-I8FEL:71Y('1O(&%T=&%C:"!A;B!E
M>'1E<FX@9FEL97-Y<W1E;3\@5VAE<F4@8V%N($D@9V5T7`I);F9O<FUA=&EO
M;B!A8F]U="!T:&ES/UP*7`I-86-54"!W<FET97,@=&AA="!T:&4@;F5W($\N
M0RY%+49I;F1E<B!W:6QL(&)E('-H:7!E9"!T:&ES(&9A;&PN($AA<R!A;GEO
M;F5<"FEN9F]R;6%T:6]N<R!O;B!H;W<@=&\@97AT96YD('1H92!/+D,N12XM
M;6%I;&EN9R!E;F=I;F4_7`I<"@I4:&%N:W,@9F]R(')E<&QY(&%N9"!H879E
M(&$@;FEC92!D87DL($IA;EP*7`HO+R\@($IA;B!5;&)R:6-H("TM(&9L>6YN
M("AR96UE;6)E<B!T<F]N/RE<"F\M;R`@<W1U9&5N="!A="!5;FEV97)S:71Y
M(&]F(%5L;2P@1V5R;6%N>5P*($Q<"B!?("`@861D<F5S<SH@=6QB<FEC:$!J
?=6QI82YI;F9O<FUA=&EK+G5N:2UU;&TN9&5<"@I]"F5S
`

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: 4 Jun 92 18:34:11 GMT
Organization: MacDTS Misfits

In article <[e-mail]>, ulbrich@second_next.informatik.uni-ulm.de (Jan Ulbrich) writes:
>
> Hi there,
>
> I'm working on an extern filesystem for the Macintosh, but noone can
> tell
> me how to implement one. The developer-support can't help - though it
> is
> mentioned in Inside Macintosh IV to ask them for support. Any idea
> where to
> get information from? Please...
>
> I read that the "Macintosh PC Exchange" can be extended by modules.
> Would
> this be a possibility to attach an extern filesystem? Where can I get
> Information about this?
>
> MacUP writes that the new O.C.E-Finder will be shiped this fall. Has
> anyone
> informations on how to extend the O.C.E.-mailing engine?

    There is little to no support for external file systems at the
moment.  Howver, one can be written- they're used for the ISO 9660,
High Sierra, and Audio CD formats on Apple CD-ROM drives.  However,
here are my warnings: They can only be made to work on read-only
systems.  It is our estimate that it will take a really expert
Mac programmer 2 years to write one.  This programmer will spend
75% of her time bashine her head against the ugliest bits of the
Mac.  If it sounds like I'm trying to scare you, I am.  This is not
a project to be attempted lightly.

Tim Dierks
MacDTS, but I speak for the trees

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Urlichs)
Date: 23 Jun 92 18:17:40 GMT
Organization: University of Karlsruhe, FRG

In comp.sys.mac.programmer, article <[e-mail]>,
  [e-mail] (Tim Dierks, software saboteur) writes:
< In article <[e-mail]>, ulbrich@second_next.informatik.uni-ulm.de (Jan Ulbrich) writes:
< >
< > Hi there,
< >
< > I'm working on an extern filesystem for the Macintosh, but noone can  tell
< > me how to implement one. The developer-support can't help - though it is
< > mentioned in Inside Macintosh IV to ask them for support. Any idea where to
< > get information from? Please...
<
<     There is little to no support for external file systems at the
< moment.  Howver, one can be written- they're used for the ISO 9660,
< High Sierra, and Audio CD formats on Apple CD-ROM drives.  However,
< here are my warnings: They can only be made to work on read-only
< systems.  It is our estimate that it will take a really expert
< Mac programmer 2 years to write one.  This programmer will spend
< 75% of her time bashine her head against the ugliest bits of the
< Mac.  If it sounds like I'm trying to scare you, I am.  This is not
< a project to be attempted lightly.

But what are AppleShare or MacNFS, if not external file systems?
And these certainly aren't write-only.  ;-)

BTW, this is a good alternate way to write an external file system -- just
emulate an AppleShare file server and plug your external file system support
code into its back end. Source code to do this is available via FTP from
iraun1.ira.uka.de, directory /pub/mac.

- --
Boob's Law:
        You always find something in the last place you look.
- --
Matthias Urlichs  --  [e-mail] -- [e-mail]   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  [phone]     \o)/

---------------------------

From: [e-mail] (Kent P Miller)
Subject: Drawing a "graph" of a sound
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA
Date: Fri, 5 Jun 1992 16:59:47 GMT

I am trying to write a procedure that will draw a graphical representation
of a sound sort of like Sound Edit or the HyperCard sound stuff.  Here's the
problem:

If I make a picture using every single point in the sound, it is too slow.
If I just skip through the sound (with every 10th point or so), I might not
get a true representation of the sound.  My idea is to only
check every point and just graph the max/min of every 20th point or so.

Has anyone done this and if so, how did you do it?

Thanks for any help you can offer.  If I am emailed, I will summarize.

Kent
- --
- -----------------------
Kent Miller
[e-mail]
- -----------------------

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 9 Jun 92 06:53:49 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Kent P Miller) writes:
>
> I am trying to write a procedure that will draw a graphical representation
> of a sound sort of like Sound Edit or the HyperCard sound stuff.  Here's the
> problem:
>
> If I make a picture using every single point in the sound, it is too slow.
> If I just skip through the sound (with every 10th point or so), I might not
> get a true representation of the sound.  My idea is to only
> check every point and just graph the max/min of every 20th point or so.
>
> Has anyone done this and if so, how did you do it?
>
> Thanks for any help you can offer.  If I am emailed, I will summarize.

First, you have to decide what the scaling factor is.  There are two
variables: the length of the data and the length of the picture.

You divide the data length by the picture's length.
This gives you the increment factor.
Draw the first sample of the data at picture's position zero.
Add increment to the index, and get the next sample from the array.
Do this until the length of the picture.

You also have to scale the amplitudes to the picture's height.

Remember that $80 is the zero crossing, meaning that $80 is silence.
The maximum value is $FF and the minumum is $00.



- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Roger Allen)
Date: 11 Jun 92 20:55:57 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <[e-mail]> [e-mail] (Jim Reekes) writes:
>In article <[e-mail]>, [e-mail] (Kent P Miller) writes:
>>
>> I am trying to write a procedure that will draw a graphical representation
>> of a sound sort of like Sound Edit or the HyperCard sound stuff.  Here's the
>> problem:
>>
>> If I make a picture using every single point in the sound, it is too slow.
>> If I just skip through the sound (with every 10th point or so), I might not
>> get a true representation of the sound.  My idea is to only
>> check every point and just graph the max/min of every 20th point or so.
>>
>> Has anyone done this and if so, how did you do it?
>>
>> Thanks for any help you can offer.  If I am emailed, I will summarize.
>
>First, you have to decide what the scaling factor is.  There are two
>variables: the length of the data and the length of the picture.
>
>You divide the data length by the picture's length.
>This gives you the increment factor.
>Draw the first sample of the data at picture's position zero.
>Add increment to the index, and get the next sample from the array.
>Do this until the length of the picture.
>
>You also have to scale the amplitudes to the picture's height.
>
>Remember that $80 is the zero crossing, meaning that $80 is silence.
>The maximum value is $FF and the minumum is $00.
>

Another thing to keep in mind is, how much is the user going to be looking
at?  If the user is only going to be looking at 200 points of a 20k
sound, then only draw those 200 points at a time.

I have been working on a program that does this and had similar problems.
What I USED to do was:

1. Draw the ENTIRE sound to an offscreen buffer (or a scaled sound if
   length > 32k).
2. Copybits the part that the user was looking at to the screen.

But, number 1 takes a LONG time for long sounds and for me this was
unacceptable.

So, what I changed to was:

1. Convert the sound data points to y coordinates and store. (i.e. FF -> 0
   and 0 -> maxY)  This doesn't take too long, but occupies space.
2. Then, draw what the user is looking at into an offscreen buffer that is
   the size of the window, then copybits this to the window.  If you just
   draw directly to the window, the user can see this.

However, my way is still not the fastest since SoundEdit is lots faster.

I asked this before and I'll ask again...How does SoundEdit do it???

Hope this helps,
Roger
- --
> Roger Allen                   |  All the opinions expressed are my     <
> Amdahl Computer Development   |  own and are not Amdahl's.             <
> [e-mail]           |  ------They paid me to say that------- <

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 12 Jun 92 18:24:42 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Roger Allen) writes:
>
> I have been working on a program that does this and had similar problems.
> What I USED to do was:
>
> 1. Draw the ENTIRE sound to an offscreen buffer (or a scaled sound if
>    length > 32k).
> 2. Copybits the part that the user was looking at to the screen.
>
> But, number 1 takes a LONG time for long sounds and for me this was
> unacceptable.
>
> So, what I changed to was:
>
> 1. Convert the sound data points to y coordinates and store. (i.e. FF -> 0
>    and 0 -> maxY)  This doesn't take too long, but occupies space.
> 2. Then, draw what the user is looking at into an offscreen buffer that is
>    the size of the window, then copybits this to the window.  If you just
>    draw directly to the window, the user can see this.
>
> However, my way is still not the fastest since SoundEdit is lots faster.
>
> I asked this before and I'll ask again...How does SoundEdit do it???

Here's an idea: create an offscreen bitmap, but don't use QuickDraw to
draw the samples into it. Instead, directly compute which bits to set, and
set them yourself with some carefully-written custom code. Then use CopyBits
to draw the result to the screen display.

This should speed things up a bit, without getting into complications of
different screen depths and screen addressability (and clip regions), which
you would get into if you started directly setting screen pixels...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Calamity theory claims that there are only seven different kinds of misfortunes
that you can suffer. These can be distinguished by the different patterns of
cracks left when your body hits the pavement.

+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Sat, 13 Jun 1992 04:38:56 GMT

Actually, the technique of using custom code to draw to an offscreen bitmap,
then CopyBits()ing it to the screen is completely general and fast, since
CopyBits allows any kind of scren to be the destination. I've used this
techgnique to implement oscilliscopes that drew on 24-bit deep displays,
and gotten many complete screen-fulls per second out of it, provided you
also keep track of the min and max x, and y coordinates that you need to
CopyBits() so you send the smallest rectangle you can.  Here's a tip:
rather than using an offscreen bitmap, use an offscreen 1-bit deep grafport.
This lets you set the foreground and background color. When you CopyBits
to a color screen, CopyBits will look at those colores, and draw your 1-bit
deep bitmap appropriately.  You don't get a big choiuce of colors, but sometimes
it is better than boring old black and white.  There is a tech note on this
kind of "Colorization" you can check in case I've gotten it wrong and it is
the destinatins's foreground and background colors you should set.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 Jun 92 20:37:14 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Roger Allen) writes:
>
> Another thing to keep in mind is, how much is the user going to be looking
> at?  If the user is only going to be looking at 200 points of a 20k
> sound, then only draw those 200 points at a time.
>
> I have been working on a program that does this and had similar problems.
> What I USED to do was:
>
> 1. Draw the ENTIRE sound to an offscreen buffer (or a scaled sound if
>    length > 32k).
> 2. Copybits the part that the user was looking at to the screen.
>
> But, number 1 takes a LONG time for long sounds and for me this was
> unacceptable.
>
> So, what I changed to was:
>
> 1. Convert the sound data points to y coordinates and store. (i.e. FF -> 0
>    and 0 -> maxY)  This doesn't take too long, but occupies space.
> 2. Then, draw what the user is looking at into an offscreen buffer that is
>    the size of the window, then copybits this to the window.  If you just
>    draw directly to the window, the user can see this.
>
> However, my way is still not the fastest since SoundEdit is lots faster.
>
> I asked this before and I'll ask again...How does SoundEdit do it???



Below is a routine I used a few years ago in a MacApp application that I was
writing that could display a sound buffer.  I found that this routine was
fast enough, and I didn't need any offscreen buffers.  Upon looking at it
now, I can see some optimazations I can make but as I said when I used this
code I felt it was fast enough.

Hopefully the code is obvious enough.  I should point out that I draw a
gray area at the end of the sound, to show the use an area after the sound.
The length of this empty space is the constant kGrayArea.  Also note that it
only draws the exact number of sound bytes necessary to fill the display
and no more.  In other words, if you're view is 300 pixels in width this
routine will only draw 300 different bytes of the sound.


PROCEDURE TSampleDataView.Draw(area: Rect); OVERRIDE;

VAR
   byteWanted, offset, dataLength:  LONGINT;
   sampleArrayPtr:                  sampleAreaArrayPtr;
   areaVRect:                       VRect;
   hPos:                            Integer;
   endRect:                         Rect;
   dataPtr:                         Ptr;
   ourDialogView:                   TSampleSndEditor;

BEGIN
   PenNormal;
   dataPtr:= StripAddress(fSndResource.ReturnHandle^);
   dataPtr:= Ptr(ORD4(dataPtr) + fSndResource.GetSoundDataOffset);
   sampleArrayPtr:= sampleAreaArrayPtr(ORD4(dataPtr) + 22); { point to sample area }
   dataLength:=fSndResource.GetBufferLength;
   offset:= (dataLength - 1) DIV (fSize.h - kGrayArea);  { length is zero based }
   QDToViewRect(area, areaVRect);         { get the current area in relative to view }
   byteWanted:= areaVRect.left * offset;  { sample byte is positioned relative to view.h }
   hPos:= area.left;

   { we want to make the line contiguous, so get the previous byte }
   { if the first byte wanted is less than first position in view...}
   IF byteWanted < offset THEN
      MoveTo(hPos, (255 - sampleArrayPtr^[0]) DIV 2)  { then get the first byte of sample }
   ELSE                                               { otherwise, get the previous byte }
      MoveTo(hPos - 1, (255 - (sampleArrayPtr^[byteWanted - offset])) DIV 2);

   WHILE (hPos <= area.right) & (byteWanted <= dataLength - 1) DO
      BEGIN
         LineTo(hPos, (255 - (sampleArrayPtr^[byteWanted])) DIV 2);
         byteWanted:= byteWanted + offset;         { skip to the next byte in sample array }
         hPos:= hPos + 1;                          { goto the next horz position }
      END;

   { create a rect that is the ending gray area }
   areaVRect.top:= 0;
   areaVRect.left:= fSize.h - kGrayArea;
   areaVRect.bottom:= fSize.v;
   areaVRect.right:= fSize.h;
   ViewToQDRect(areaVRect, endRect);

   { if the ending gray area is not within view, then don't bother }
   IF endRect.left < area.right THEN
      BEGIN
         MoveTo(endRect.left, endRect.top);
         LineTo(endRect.left, endRect.bottom);
         { bump the gray rect to the left one, keeping the line just drawn }
         OffSetRect(endRect, 1, 0);
         FillRect(endRect, gray);   { this will move memory! }
      END;

   ourDialogView:= TSampleSndEditor(GetDialogView);
   FailNIL(ourDialogView);
   IF ourDialogView.WantsLoopArea THEN
      ShowLoopArea;
END;



- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 22 Jun 92 00:34:42 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (David Phillip Oster) writes:
>
> Actually, the technique of using custom code to draw to an offscreen bitmap,
> then CopyBits()ing it to the screen is completely general and fast, since
> CopyBits allows any kind of scren to be the destination. I've used this
> techgnique to implement oscilliscopes that drew on 24-bit deep displays,
> and gotten many complete screen-fulls per second out of it, provided you
> also keep track of the min and max x, and y coordinates that you need to
> CopyBits() so you send the smallest rectangle you can.  Here's a tip:
> rather than using an offscreen bitmap, use an offscreen 1-bit deep grafport.
> This lets you set the foreground and background color. When you CopyBits
> to a color screen, CopyBits will look at those colores, and draw your 1-bit
> deep bitmap appropriately.  You don't get a big choiuce of colors, but sometimes
> it is better than boring old black and white.  There is a tech note on this
> kind of "Colorization" you can check in case I've gotten it wrong and it is
> the destinatins's foreground and background colors you should set.

Below is a routine I used a few years ago in a MacApp application that I was
writing that could display a sound buffer.  I found that this routine was
fast enough, and I didn't need any offscreen buffers.  Upon looking at it
now, I can see some optimazations I can make but as I said when I used this
code I felt it was fast enough.

Hopefully the code is obvious enough.  I should point out that I draw a
gray area at the end of the sound, to show the use an area after the sound.
The length of this empty space is the constant kGrayArea.  Also note that it
only draws the exact number of sound bytes necessary to fill the display
and no more.  In other words, if you're view is 300 pixels in width this
routine will only draw 300 different bytes of the sound.


PROCEDURE TSampleDataView.Draw(area: Rect); OVERRIDE;

VAR
   byteWanted, offset, dataLength:  LONGINT;
   sampleArrayPtr:                  sampleAreaArrayPtr;
   areaVRect:                       VRect;
   hPos:                            Integer;
   endRect:                         Rect;
   dataPtr:                         Ptr;
   ourDialogView:                   TSampleSndEditor;

BEGIN
   PenNormal;
   dataPtr:= StripAddress(fSndResource.ReturnHandle^);
   dataPtr:= Ptr(ORD4(dataPtr) + fSndResource.GetSoundDataOffset);
   sampleArrayPtr:= sampleAreaArrayPtr(ORD4(dataPtr) + 22); { point to sample area }
   dataLength:=fSndResource.GetBufferLength;
   offset:= (dataLength - 1) DIV (fSize.h - kGrayArea);  { length is zero based }
   QDToViewRect(area, areaVRect);         { get the current area in relative to view }
   byteWanted:= areaVRect.left * offset;  { sample byte is positioned relative to view.h }
   hPos:= area.left;

   { we want to make the line contiguous, so get the previous byte }
   { if the first byte wanted is less than first position in view...}
   IF byteWanted < offset THEN
      MoveTo(hPos, (255 - sampleArrayPtr^[0]) DIV 2)  { then get the first byte of sample }
   ELSE                                               { otherwise, get the previous byte }
      MoveTo(hPos - 1, (255 - (sampleArrayPtr^[byteWanted - offset])) DIV 2);

   WHILE (hPos <= area.right) & (byteWanted <= dataLength - 1) DO
      BEGIN
         LineTo(hPos, (255 - (sampleArrayPtr^[byteWanted])) DIV 2);
         byteWanted:= byteWanted + offset;         { skip to the next byte in sample array }
         hPos:= hPos + 1;                          { goto the next horz position }
      END;

   { create a rect that is the ending gray area }
   areaVRect.top:= 0;
   areaVRect.left:= fSize.h - kGrayArea;
   areaVRect.bottom:= fSize.v;
   areaVRect.right:= fSize.h;
   ViewToQDRect(areaVRect, endRect);

   { if the ending gray area is not within view, then don't bother }
   IF endRect.left < area.right THEN
      BEGIN
         MoveTo(endRect.left, endRect.top);
         LineTo(endRect.left, endRect.bottom);
         { bump the gray rect to the left one, keeping the line just drawn }
         OffSetRect(endRect, 1, 0);
         FillRect(endRect, gray);   { this will move memory! }
      END;

   ourDialogView:= TSampleSndEditor(GetDialogView);
   FailNIL(ourDialogView);
   IF ourDialogView.WantsLoopArea THEN
      ShowLoopArea;
END;



- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."


---------------------------

End of C.S.M.P. Digest
**********************